[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Extensibility methods
|
I think there is still time to join the discussion :) I my opinion we should avoid having both mechanisms, since that adds complexity without buying us anything. If we allow namespace extensions someone
will use them. If we allow the <metaHolder> someone will use it. If we allow both there will be users of both and probably some users that use both at the same time. For me the key point is to make it easier to ensure interoperability. One of the biggest obstacles to that for me in Xliff 1.2 is the use of third
party namespaces. Even if the schema is public it is close to impossible to support them in a generic tool. Besides the difficulty in displaying / interacting with the data in them, they pose a risk to the document validity when editing the document without
knowledge of the third party schema and how it works, think references from the extension schema to elements in the core standard. They also invite tools to make complicated extensions of the standard that is hard to support in other tools and thus often break
when the file is processed by such tools. The <metaHolder> / <prop-group> style extensibility provides a more restricted extension method that will likely be easier to support cross tools.
Obviously it will not remove the fact that you can make extensions that is not interoperable. But at least it is less inviting to do so. I also think it is easier for us creating the standard to impose narrow processing expectations on these elements that
improve the interoperability, than it is to restrict the workings of third party namespace extensions. Finally the point I raised in the beginning of this thread about the ability to display / interact with unknown data is appealing to me. I do see the benefit of using namespace extensions to create proprietary extensions. Adding a new attribute to an existing node to attach some
data is more elegant than adding it in a key/value group. Not to speak of more complicated extensions. It is just that I do not believe we can achieve good interoperability and allow that at the same time. For the extensions created by us as ‘modules’ we should of course use namespaces. But here we are in control of both the core and all the extensions
and it would be a defect in the standard if the extensions do not work well with tools that do not support them. So we need to take carte when defining them Regards, Fredrik Estreen From: Arle Lommel [mailto:alommel@gala-global.org]
Thanks for the pointer to the proper location. I wish I'd been there for the discussion, as this is an interesting issue. I see there is some sense that it is more complex than a namespace, and there are examples to show why this is so,
but the apparent discrepancy in complexity is not so straight-forward: in cases where you use an external namespace the complexity is handled elsewhere (in the schema for the namespace), which allows for a very streamlined local representation. In cases where
you don't have that schema, metaHolder would seem to provide a way to accomplish things at the price of a more complex local mechanism. If we take both approaches (which I think makes sense) we would need to clearly distinguish the use cases for each one in
the documentation (which shouldn't be too hard to do). -Arle Sic scripsit Estreen, Fredrik in May 3, 2012 ad 10:41 :
Hi Arle, There is a proposal on the Feature tracker for this: Preserve metadata without using extensibility. I think the feature has changed a bit from
there in the discussions since but the general structure of the XML is there. There has also been some more recent discussion, especially in the threads started at : Regards, Fredrik Estreen From: Arle
Lommel [mailto:alommel@gala-global.org] Hi all, I'm just now back in Berlin. Apologies for missing Tuesday's call, but I trust being in transit to another country is a good reason to miss… I read this and am intrigued the the metaHolder element. Would it be possible to see a "live" example of what it would look like? I don't think I've seen one (or I've missed it), but Jung’s explanation is quite compelling to me. From an
implementation standpoint if you want to pass along some sort of internal metadata that may be useful, but you do not have a schema for it (or perhaps it was created ad hoc for a particular one-off project), this seems like a useful way to go, bearing in mind
the caveats expressed here. It would seem to hit the sweet spot for situations where something light is needed. But based on what I've read in the trail below, I would end up voting to allow both metaHolder and custom namespaces since I think they meet distinct
(albeit related) needs. -Arle Sic scripsit Yves Savourel in May 2, 2012 ad 03:26 :
Hi Fredrik, Jung, At last, good technical reasons to use something like <metaHolder>. I’m still not convinced it would be better than custom namespaces, but at least now I can see positive implementation aspects to it. I need to chew on that. +1 for Fredrik’s suggestion on the way to moving forward. Cheers, -yves From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On
Behalf Of Jung Nicholas Ryoo Hi all, Hi All, I would like to follow up on yesterday's discussion on the <metaHolder> and namespaces to facilitate extensibility. The first thing is a point which I don't think has been discussed before, and that is how easy it would be for a tool to make meaningful use of unknown extension data. At first it might sound like a nonworking or bad idea but I think there are cases where it would add value. In many cases metadata could be made useful even if the tools do not know the exact meaning of it, the problem is finding a good way to present it to the user. Here I believe that <metaHolder> as a grouped key/value store is much simpler to work with than arbitrary XML in a namespace. I also think it would make it simpler to extract the metadata for storage/retrieval in a database. Specific things that I can see a use for is filtering the document on translation units with a specific key/value pair, or providing URL links to other information (or applications). Generically it would be possible to display (and possibly modify) the unknown data as a grouped property grid allowing the user to interpret the meaning of the data. Creating a query builder interface for a database would also be straight forward. To make the filtering / querying as useful as possible I would recommend to also provide a "datatype" for the "value" so that range queries can be used and appropriate input controls created. I think it makes sense to keep the list short and also allow "unknown" as the default type. So unknown, string, number, url and date feels like a good set to me, but I'm sure there are a few more that other would like to see. Another option if we do not want to specify the list we could use some other standard list like the XML primitive types http://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes and use anySimpleType as the default / unknown. All of this is possible with XML namespace extensions, but in my opinion it is much more difficult to create user friendly access to the data. A simple but not so user friendly way here is of course to just use XPATH for search and filtering and somehow display the XML fragments to the user. Second thing is that I like the process/votes suggested David Filip and think we should start down this path to resolve the issue. First one where we simply vote if we want extensibility at all: * 'Yes' for extensibility by some means * 'No' for no extensibility at all * 'Abstain' for need of more discussion Second one where we vote on how, using 'Elements', 'Namespaces', 'Elements and Namespaces', 'Abstain' to select how to implement the extensibility, if the 'Yes' votes won the first vote: * 'Elements' for extensibility by elements and attributes defined in the XLIFF specification. An example of this method is the proposed <metaHolder> feature. * 'Namespaces' for extensibility by allowing third party namespaces at defined locations in the XLIFF documents. As we do in XLIFF 1.2 possibly with additional requirements for conformance and processing expectations. * 'Elements and Namespaces' to use both of the above methods to facilitate extensibility. * 'Abstain' for need of more discussion If we choose to allow extensibility and the preferred way(s) to do it we can start looking at the implementation details. Regards, Fredrik Estreen --------------------------------------------------------------------- To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xliff-help@lists.oasis-open.org -- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]