Re: MicroXML design goals

On Tue, Aug 14, 2012 at 9:40 AM, John Cowan <cowan@mercury.ccil.org> wrote:

> Uche Ogbuji scripsit:
>
> > I propose that the next iteration MicroXML draft cover just xml:lang and
> > xml:space.  I don't want to discard xml:id and xml:base, but I think
> these
> > belong in a separate layer, and even if they are added to the core we can
> > argue doing so in a later iteration.
>
> I disagree entirely.  xml:id and xml:base are much more important than
> xml:space, which is mostly superseded by the space-handling facilities
> of XSLT.  In particular, we should encourage document and schema authors
> to use xml:id from day one, making it the de facto standard for element
> identification in MicroXML documents.
>
> I think the idea of xml:space was that it would be put into the XHTML DTD
> so that XHTML processors could determine by its presence which elements
> preserved space without needing hard-coded knowledge.  In the end,
> neither DTDs nor XHTML have been winners.
>

Well yes, it's basically the pre and script element case, which I've used,
but yes I can do without far more easily than xml:lang.

So I'm OK dropping xml:space from the MicroXML spec.

As for xml:id and xml:base, I'm just suggesting they be argued for addition
at a later stage.  Again I'm mostly interested right now in the minimum
increment to the Starting Point grammar, and I think that includes
xml:lang, which informs the question of colons in attribute names.

I wouldn't think to preclude later increments.


> For one thing, if we talk xml:base in the spec we would probably want to
> > add a baseuri property on the element model, and ditto for an id property
> > re xml:id.  It would be nice to avoid that.
>
> Those are convenience or (less politely) junk properties.  We shouldn't
> put anything into the data model that's not logically required.
>
> That doesn't mean that they should not be present in a practical API.
> The MicroLark Element object provides getLanguage and getId methods that
> just search up the tree, a relatively cheap operation.
>

I think if we expect these to be in every useful API that they have become
strong candidates for inclusion in the data model.  That doesn't mean that
every API must track them on each node. There could easily be computed on
request, as you say.  But the wording you have in your draft for xml:id and
xml:base amount to an addition to the data model, even if you don't
explicitly have them in a section entitled "data model."  I wonder what is
the benefit of having such implicit properties.



> > Maybe the core data model should mention that additional specifications
> can
> > augment the core properties. Sure that could be implicit, but it's worth
> > signaling.
>
> I suppose, though I am no fan of the PSVI.  Still, type annotations
> would make some sense.
>

I am definitely no fan of the PSVI, but I don't have to be if further
annotations are relegated to a separate level. If someone else wants to
create a MicroXSD, I don't think we should stand in their way, but we are
not obligated to use it, either.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji