jakobib / hypertext2019

Paper and poster to revive the original idea of hypertext based on transclusion
https://jakobib.github.io/hypertext2019/
11 stars 1 forks source link

Specify YAML Xanadoc format #5

Closed ghost closed 1 year ago

ghost commented 2 years ago

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

# key-value
http: '//hyperland.com/xuCambDemo/WelcXu-D1y,start=25,length=567'

1.2 sample 2: hyperland_xuCambDemo2.yaml

# key-value
http: '//hyperland.com/xuCambDemo/WelcXu-D1y,'
start: '25'
length: '567'

2. Idea

2.1 symbol

# key-value
# protocol or url: http|https|sft|ftp|ssh
protocol: address

What do you all think about this... use case?

nichtich commented 2 years 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

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.

nichtich commented 2 years ago

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.

nichtich commented 2 years ago

@codehangen 🤯 I am very sorry for having deleted your comment by accident!

ghost commented 2 years ago

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?

What is WebQuery?

"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?

nichtich commented 2 years ago

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.

ghost commented 1 year ago

Hi nichtich, thank you for feedback. I'm closing this issue, all my questions have been answered.