Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 05 2017 17:37

    sakamies on master

    todos (compare)

  • Mar 03 2017 18:37

    sakamies on master

    formatting (compare)

  • Mar 03 2017 18:36

    sakamies on master

    different color for attr/value … deleting empty items added usel… notes and 1 more (compare)

  • Mar 03 2017 18:11

    sakamies on master

    Update README.md (compare)

  • Mar 03 2017 18:10

    sakamies on master

    Update README.md (compare)

  • Mar 03 2017 17:42

    sakamies on master

    keep values tied to their props (compare)

  • Mar 03 2017 16:56

    sakamies on master

    less confusing tag/txt editing … (compare)

  • Mar 03 2017 16:47

    sakamies on master

    some very basic copy & paste sa… (compare)

  • Feb 28 2017 16:49

    sakamies on master

    Update README.md (compare)

  • Feb 28 2017 16:49

    sakamies on master

    Update README.md (compare)

  • Feb 28 2017 16:25
    sakamies closed #6
  • Feb 28 2017 16:23

    sakamies on master

    Update README.md (compare)

  • Feb 28 2017 16:22

    sakamies on master

    Update README.md (compare)

  • Feb 28 2017 16:22

    sakamies on master

    Update README.md (compare)

  • Feb 28 2017 16:22

    sakamies on master

    Update README.md (compare)

  • Feb 27 2017 19:04
    matthewfcarlson opened #6
  • Feb 27 2017 16:32

    sakamies on master

    clean up (compare)

  • Feb 24 2017 18:35

    sakamies on master

    rudimentary copy paste (compare)

  • Feb 23 2017 17:59

    sakamies on master

    styling fix error when trying to add pr… implement additive selection vi… and 1 more (compare)

  • Feb 22 2017 18:46

    sakamies on master

    todo (compare)

Risord
@Risord
After that I continue work for put all these technoligies together by code. That phase can still take couple of weeks...
Ville V. Vanninen
@sakamies
alrighty 👍
I'd love to see some broad terms explanation of what the schema would define and how we'll use it
I managed to code a little bit of interactions in the proto this week
Risord
@Risord
If you want we can take some voip meet tomorrow.
After 18 maybe?
Ville V. Vanninen
@sakamies
sure, after 18 is good
Ville V. Vanninen
@sakamies
@Risord did you mean tomorrow or tomorrow? :D either is good though
Risord
@Risord
@sakamies "Today tomorrow" :D
Ville V. Vanninen
@sakamies
what's your preference? skype/google hangout/something?
Risord
@Risord
Ok it seems that there are some sort of SHACL implementation for JS
sadly it's not open source
Risord
@Risord
Many thanks to Holger Knublauch and TopQuadrant. SHACL JS validator is now open source.
https://github.com/TopQuadrant/shacl/tree/master/src/main/resources/etc
Risord
@Risord
It seems that there are basicly two main ways to create html-metamodel
A:
class Element {
    tagName : String
    attributes : Attribute[]
    children : Element[]
}
B:
class TableElement {
    id : String?
    style : String?
    caption : CaptionElement?
    rows : TrElement[]
}
We can say that A is traditional dom like model. If you want create table element, just name it as table and insert relevant elements as children etc
This kind of model might fit quite well for editor which tries to act as 'visual source editor'
Risord
@Risord
So editor like most of structural html editors and FoolProof is
However creating schema for such model is not quite easy. I believe (but just believe) that actually validating that with SHACL is possible but it will be hard. So after this very simple surface metamodel will be quite complex.
Risord
@Risord
B model is much better for validating and actually describing the model but it may not be as editor friendly as A
of course we are talking about that spesific editor class
But yeah.
B models HTML as abstract model.
A models serialization format of HTML so schemaless XML / SGML for example.
Ville V. Vanninen
@sakamies
interesting
that b model would require active maintenance, the modern html spec changes quite often
I'd really prefer A, it's so much more flexible
Ville V. Vanninen
@sakamies
there are many cases where you'll make up an element name and use that to render a component in its place
Risord
@Risord
Again custom components don't belong to html specs
but yeah I think we go with approach A for now
it's schema is basicly trivial etc
we might actually get some practical done
These advantages of course only exists if we drop these "over complex" schema rule out from A which rule for example what elements are allowed and where
Risord
@Risord
Like I said A is not a HTML model. It's schemaless XML/SQML model which can be used to build data which may happen to be HTML.
So everything something like this is valid input (quite extreme example but still):
<br cellspan="* { color :: red }">
  <mkdir>
    <html a="b">
    <p>
  </mkdir>
</br>
Risord
@Risord
More strict validation can be of course added afterwards
But this A / "format first" it's fine starting point
Risord
@Risord
But about these two possibilities: I don't think these are one or another selections but we can take both. It just question which approach should be taken as starting point.
If strict editing should be added for HTML I would say that even if we are already using A model for editors we still implement model B. We can then use mapper / "lens" / computing microeditor which will transform these models in realtime.
Risord
@Risord
Multi model is one essential feature to be handled
Same way if strict template language editing is wanted we need model "C" (B like implementation for templatete language)
Of course one can say that we don't need these since we have this "universal A" and we can build all syntax checkers on top of that. However I would say that it's pretty hacky solution and if we start supporting CSS / JS whatever non xml like we notice immediadly that model A has nothing universal.
Risord
@Risord
These strict models of course are very long term goals. I would still like to see relatively soon how multi model idea works in practice with some simple models.
Ville V. Vanninen
@sakamies
Again custom components don't belong to html specs
that's true, but they're used all the time in practice
Risord
@Risord
First if that sounded mean I am sorry.
But yea. If HTML model won't support custom template things it won't mean that these template things need to be completely unsupported or live in separated world from user viewpoint.
We have to just define same kind of model for template language as HTML.
Risord
@Risord
And then we would have strict editing which understand both HTML and template language.
But this multidomain thing is complex topic...