Closed ghost closed 1 year ago
Thanks for interest! First of all, this repository is kept in its current form and archived as it is part of publications https://jakobib.github.io/hypertext2019/ and https://doi.org/10.1145/3342220.3344922 You asked:
what you think of the yaml data serialization format. 1) Is yaml similar to xanadoc proposal?
YAML is just a data structuring format such as JSON, INI, CSV, TOML, SDLang... without any specific semantics. Each of these formats has its benfits and disadvantages and most could be used to express something like xanadoc.
To examine the example //hyperland.com/xuCambDemo/WelcXu-D1y,start=25,length=567
on abstract level it consists of
//hyperland.com/xuCambDemo/WelcXu-D1y
)start=25,length=567
)Both together are used as part of an edit list. Many file formats can be defined for edit lists, for instance specified by Nelson as XANADU PURPLE:
MediaContent = UTF8,25,567,http://hyperland.com/xuCambDemo/WelcXu-D1y
In another form of xanadoc as illustrated at https://xanadu.com/SampleEDL.txt this would be:
span: http://hyperland.com/xuCambDemo/WelcXu-D1y,start=25,length=567
Your suggestion of YAML could be used as well and it has the advantage of being easier to parse with standard YAML parser libraries (however I'd prefer JSON as YAML is more complicated). Apart from that I'd always look out for existing standards to build on. For instance there is a specification how to express a character range, so better not invent the wheel but use RFC 5147. The range start=25,length=567
in RFC 5147 would be expressed as char=25,592
(or it may be char=26,593
depending on how the specifications define start position). An edit list format should specify which locator language is used (in this case: RFC 5147), so a possible format based on YAML could be:
- document: http://hyperland.com/xuCambDemo/WelcXu-D1y
locator:
rfc5147: char=25,592
Transclusion from other document formats require other locator languages, e.g. select from JSON with (SQL/)JSON Path Language or select from XML with XPath.
There is no "fundamental advantage" of YAML compared to alternatives as every comparision depends in criteria to judge on. More important with "infrastructure-agnostic" a meant also independent from particular file formats such as YAML, JSON, INI... but support of multiple formats and protocols. Anyway, using YAML for Xanadoc is not worse than Nelson's plain-text format, so go for it.
Although the repository is archived, would there be any way I could contribute something?
I drafted a demo implementation of a hypertext system at https://github.com/nichtich/xanadoc-demo. By now it's only 68 lines of Perl and could be done in any other programming language as well. The current YAML format differs from your suggestions but nothing is fixed. Feel free to fork and play around. However I don't understand your goal. Sure you can replicate something like http://xanadu.com/xanademos/MoeJusteOrigins.html as discussed at https://gist.github.com/ldodds/a7f901c7f0118e83a645 but what's next?
What do you think about this idea?
I appreciate your enthusiasm. Best try out and start coding something. Any specification can help but I'd not call it RFC.
@codehangen 🤯 I am very sorry for having deleted your comment by accident!
Hi nichtich.
@codehangen 🤯 I am very sorry for having deleted your comment by accident!
that's ok.
Another thing I wanted to check and get some feedback on would be the web query specification. We are talking about some yaml-xanadoc specification. I think it's important initially to talk about the search specification of xanadoc documents. So... have you heard of Web Query?
"Proposal to use
.well-known/query
to query a website by a search-term. Making it possible to decentralize web search operations ..."
"Maybe this can create docuverse or xanadu-space. Imagine that every person who builds your search engine and can send indexing to distributed servers, and those same servers can provide a diverse and indexable search for any website address in a decentralized and distributed way."
What do you think about web-query in the context of searching xanadoc documents?
I've not heard of WebQuery before thanks for the pointer. On a first look I don't see how this is related to hypertext.
Hi nichtich, thank you for feedback. I'm closing this issue, all my questions have been answered.
Hi everyone.
I read your paper and found the points raised interesting, a doubt I have would be... to use yaml to serialize xanadoc data.
So... I would like to know what you all think of the yaml data serialization format. 1) Is yaml similar to xanadoc proposal? 2) Is this project active? 3) is it kept?
1. concept
1.1 sample 1: hyperland_xuCambDemo1.yaml
1.2 sample 2: hyperland_xuCambDemo2.yaml
2. Idea
2.1 symbol
What do you all think about this... use case?